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0 Preemptive and non pre-emptive scheduling and executing of program threads in a multitasldng 
operating system. 



@ A multitasking operating system permits applica- 
tion programs (and their developers) to influence a 
schedule of execution of program threads which 
constitute the application programs by specifying 
parameters for the program threads. The parameters 
indicate each thread's priority level and dispatch 
class In which the thread resides. The application 
programs specify the thread's parameters based on 
the following principles of the operating system. The 
operating system queues the highest priority thread 
available for execution from each dispatch class onto 
a run list for execution by a processor. The highest 
priority thread on the run list Is executed first. While 
this thread is dispatchable and being xecuted. no 



other thread from the same dispatch class can pre- 
empt it unless this executing thread voluntarily relin- 
quishes control of the processor, even if the other 
thread has a higher priority. (This other thread would 
have been created or made available after the cur- 
rently executing thread was selected for the run list.) 
However, the currently executing thread can be in- 
voluntarily preempted at any time by another higher 
priority, available thread from a different dispatch 
class. A thread can also voluntarily relinquish control 
of its processor at other appropriate points in the 
execution, for example, when data structures ar 
valid, to share the processor with oth r lower priority 
threads from the sam or different dispatch classes. 
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BACKGROUND OF THE INVENTION 

Th invention relates g n rally to connputer 
operating systems, and deals more particularly with 
scheduling of computer program threads for execu- 
tion in a multitasking operating system. 

Single tasking operating systems have been 
available for many years. In such systems, a com- 
puter processor executes computer programs or 
program subroutines serially, i.e. no computer pro- 
gram or program subroutine can begin to execute 
until the previous one terminates. This type of 
operating system does not make optimum use of 
the computer processor in a case where an execut- 
ing computer program or subroutine must wait for 
the occurrence of an external event (such as avail- 
ability of data or a resource) because processor 
time is wasted. This problem led to the advent of 
multitasking or multithreaded operating systems in 
which each computer program is divided into one 
or more program threads or streams of execution. 
Each of the program threads perfomis a specific 
task. While a computer processor can execute only 
one program thread at a time, if the thread being 
executed must wait for the occurrence of an exter- 
nal event, i.e. the thread becomes "non-dispatcha- 
ble", execution of the non-dispatchable thread is 
suspended and the computer processor executes 
another thread of the same or different computer 
program to optimize use of itself. 

Multitasking operating systems have also been 
extended to multiprocessor environments where 
threads of the same or different programs can 
execute in parallel on different computer proces- 
sors. While such multitasking operating systems 
optimize the use of the one or more processors, 
they do not permit the application program devel- 
oper to adequately influence the scheduling of ex- 
ecution of threads. 

US Patent 4.395.757 discloses an information 
structure called a "semaphore" which is available 
to an application program developer and serves as 
a signalling mechanism to coordinate or synchro- 
nize a computer process and an event or resource. 
The semaphore indicates the presence of events or 
resources waiting for a process to utilize them, or 
alternately, the presence of a process waiting for 
events or resources. If more than one event or 
resource, or process is present at one time, they 
may be queued awaiting the matching process, or 
event or resourc , resp ctively. 

US Pat nt 4,658,351 disclos s tiie use of prior- 
ity levels and s maphores to coordinate tasks in a 
multitasking operating system. Multipi task 
qu ues are established, on for all tasks which ar 
ready to run and hav the same priority level. A 
task control block is generat d to represent each 
task and is stored in the task queue corr spending 



to the task's priority level. Apparently the sequenc 
of the task control blocks in each task queue is 
based upon the order in which the corr spending 
task became ready to run. Tasks are executed in a 
5 sequence depending upon the relative priorities of 
the task queues and upon the locations of the task 
control blocks in each task queue. Event signalling 
and message passing are handled by semaphores. 
A publication entitled "Scheduling Techniques 

10 for Concurrent Systems" by John K. Ousterhout in 
the Proceedings of the Third International Con- 
ference on Distributed Computing Systems, 1982 
discloses that program threads are organized into 
different classes. During a time "slice", all dis- 

75 patchable program threads from one class or a 
fragment of the dispatchable threads in one class 
are executed concurrently on a like number of 
processors. At the end of a time slice, aJI executing 
threads are preempted by other dispatchabi 

20 threads. 

While the foregoing techniques permit an ap- 
plication program developer to influence the order 
of execution, further improvements are deem d 
important to permit greater control by the applica- 

25 tion program developer. Generally, controls placed 
upon the execution order of the threads, by elth r 
the operating system or the application program 
developer, decrease operating efficiency. Ideally, 
the operating system should schedule the execu- 

30 tion of the threads in as efficient a manner as 
permitted by the application program. 

A general object of the present invention Is to 
provide a multitasking operating system which op- 
timizes the execution of threads, while permitting 

35 application programs to substantially influence th 
execution schedule. 

Another object of the present invention is to 
provide a multitasking operating system of the fore- 
going types which can operate in either a single 

40 processor or multiprocessor computer system. 

SUMMARY OF THE INVENTION 

The invention resides in a multitasking operat- 
45 ing system which permits application programs 
(and their developers) to influence a schedule of 
execution of program threads derived from th 
application programs by specifying parameters for 
the program threads. The parameters indicate each 
50 thread's priority level and dispatch class in which 
the thread r sides. Bas d on thes parameters, th 
operating system sch dules threads for ex cution 
in the following fashion. The op rating system 
queues the high st priority thread which is avail- 
55 abl for execution from each dispatch class onto a 
run list for execution by a processor. The highest 
priority thread on th run list is executed first. 
White this thread is dispatchable and b ing ex- 
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ecuted, no other thread from the same dispatch 
class can preempt it unless this executing thread 
voluntarily relinquishes control of the processor, 
even if the other thread has a higher priority. (This 
other thread would have been created or made 5 
available after the currently executing thread was 
selected for the run list). However, the currently 
ex cuting thread can be (involuntarily) preempted 
at any time by another higher priority, available 
thr ad from a different dispatch class. A thread can to 
also be programmed to voluntarily relinquish con- 
trol of its processor at other appropriate points in 
the execution, for example, when data structures 
ar valid, to share the processor with other lower 
priority threads from the same or different dispatch 75 
class. 

The invention operates as follows. The operat- 
ing system organizes each thread into the class 
sp cified by the application program that created 
the thread. Each class includes at least one thread. 20 
Th operating system identifies the highest priority 
thread which is available for execution from each 
class and positions these threads on the run list for 
ex cution by one or more processors. The highest 
priority thread on the run list is tal<en off the run list 25 
and executed first. This thread continues to ex- 
ecute until it becomes non-dispatchable. completes 
execution, is preempted by a higher priority thread 
from another dispatch class (which was created or 
made available after the currently executing thread 30 
began execution) or voluntarily relinquishes control 
to the highest priority available thread from any 
dispatch class. In all of these cases, the run list can 
be updated before the preemption occurs to permit 
newly created or newly available threads to vie for 35 
th processor. 

BRIEF DESCRIPTION OF THE FIGURES 

Fig. 1 is a block diagram illustrating com- 40 
ponents of a multitaslting operating 
system which schedule program 
threads for execution according to 
the present invention. 

Fig. 2 illustrates the fields of a thread state 45 
descriptor (TSD) which is created to 
specify parameters of a program 
thread for use by the operating sys- 
tem of Fig. 1 , 

Fig. 3 illustrates the fields of a dispatch 50 
class descriptor (DCD) which is cre- 
ated to organize the thread state 
descriptors of Rg. 1 . 

Fig. 4 illustrates chaining of thread state 

descriptors within each dispatch 55 
class of Fig. 1 and linking of ail of 
the dispatch classes to each other. 

Fig. 5 is a flowchart illustrating a Thread- 



Create function within the op rating 
system of Rg. 1 . 

Fig. 6 illustrates chaining of thread state 
descriptors to form a run list within 
the operating system of Rg. 1. 

Rg. 7 is a flowchart illustrating a Promote 
primitive function within the operating 
system of Rg. 1. 

Fig. 8 is a flowchart illustrating a Schedule 
primitive function within the operating 
system of Rg. 1. 

Fig. 9 is a flowchart illustrating a Switch 
primitive function within the operating 
system of Rg. 1. 

Fig. 10 is a flowchart illustrating a Block 
primitive function within the operating 
system of Rg. 1 . 

Fig. 11 is a flowchart illustrating an Unblock 
primitive function within the operating 
system of Rg. 1. 

Fig. 12 is a flowchart illustrating a Thread- 
Suspend function within the operat- 
ing system of Rg. 1 . 

Fig. 13 is a flowchart illustrating an Unsched- 
ule primitive function within the op- 
erating system of Rg. 1. 

Rg. 14 is a flowchart illustrating a 
ThreadResume function within the 
operating system of Fig. 1. 

Fig. 15 is a flowchart illustrating a Thread- 
Delete function within the operating 
system of Fig. 1. 

Fig. 16 is a flowchart illustrating a Thread- 
SetPriority function within the operat- 
ing system of Fig. 1. 

Fig. 17 is a flowchart illustrating a Thread- 
SetDispatchClass function within the 
operating system of Fig. 1 . 

Fig. 18 is a flowchart illustrating a 
ThreadYield function within the op- 
erating system of Fig. 1. 

Fig. 19 is a flowchart illustrating a Modified- 
Schedule primitive function within the 
operating system of Fig. 1. 



DETAILED DESCRIPTION 
EMBODIMENTS 



OF THE PREFERRED 



Referring now to the figures in detail wherein 
like reference numerals indicate like elements 
throughout the several views. Rg. 1 illustrat s a 
multitasking operating system gen rally designat d 
10 and associated computer proc ssors 14a-c and 
application programs 12a-c. The operating system 
10 is preferably programmed in executable form 
onto a computer readable medium such as a mag- 
netic disk or tape, load d into a computer memory 
and executed on one or more of the CPUs 14a-c, 



4 



5 



EP 0 527 392 A2 



6 



Howev r. the operating system 10 or part ther of 
could also be implem nted by equivalent hardware. 
Operating syst m 10 can be us d in a van ty of 
types of computer systems including personal 
computers, mainframes (virtual machine and non- 
virtual machine types) etc.. and provides such stan- 
dard functions as interprocess communications, 
timing services, abnormal end handling, tracing and 
accounting functions. In addition, operating system 
10 is programmed according to the present inven- 
tion to schedule execution of application program 
threads constituting one or more of the application 
programs 12a. 12b and 12c with efficient use of 
one or more of the CPUs 14a-c. Operating system 
10 permits the application programs to substan- 
tially influence the schedule of execution of their 
threads. 

To begin the process of executing the applica- 
tion program threads, application programs 12a. 
12b and 12c call ThreadCreate function 15 once for 
each thread to be created, to define to the operat- 
ing system the threads which constitute the re- 
spective application programs. Each thread is com- 
posed of a sequence of program steps obtained 
directly from the respective application program 
and other subroutines provided by operating sys- 
tem 10 in response to calls by the program steps 
and executed in one common stream. 

The call to the ThreadCreate function includes 
the following parameters: 

1) the address of the first instruction of the 
thread (the address was determined when the 
application program was loaded Into memory), 

2) an initial priority level of the thread, 

3) an indicator of the dispatch class in which the 
thread should reside, and 

4) other parameters such as data for use or 
processing by the thread. 

The application programs (as written by ap- 
plication program developers) select each thread's 
priority and dispatch class based on the following 
principles of operating system 10: (1) the highest 
priority available (i.e. unblocked and unsuspended) 
thread from each dispatch class is queued on a run 
list 32 for execution. (2) the highest priority thread 
on the run list is executed first, (3) no thread in any 
dispatch class can preempt any other executing 
thread in the same dispatch class, (4) an unblocked 
and unsuspended thread in any dispatch class can 
preempt a lower priority executing thread in a 
different dispatch class. (5) an executing thr ad in 
any dispatch class can voluntarily relinquish control 
to the high st priority, unblocked and unsusp nded 
thread which may be in the same or different 
dispatch class, and (6) an executing thread blocks 
itself and loses control to another thread from th 
same or different dispatch class if the thr ad en- 
counters a non-dispatchable situation. The term 
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"preemption" means the act of one thread sub- 
stituting itself for another executing, dispatchable 
thread on the CPU. Th threads in a dispatch class 
may be part of the same or different application 

5 programs or processes within one application pro- 
gram. Likewise, the threads in a single process 
may reside in different dispatch classes. 

In response to the call, the ThreadCreate func- 
tion 15 in step 86 of Fig. 5 creates a thread state 

10 descriptor (TSD) 19 to describe the thread in a 
form usable by the operating system. If the thread 
is the first in the dispatch class, the ThreadCreate 
function also creates a dispatch class descriptor 
(DCD) to describe a dispatch class in which the 

75 thread resides. Each thread resides in one dispatch 
class at any one time as defined by the application 
program which created the thread. Fig. 1 illustrates 
only three dispatch classes 16. 18 and 20 although 
typically many more dispatch classes are created 

20 to execute multiple application programs. The 
ThreadCreate function also positions or chains the 
TSDs in each dispatch class in order of their rela- 
tive priority level (step 88). If the newly created 
thread has a priority equal to the priority of one or 

25 more threads already residing in the class, then the 
TSD of the newly created thread is placed in th 
dispatch class list after the TSDs of threads of lik 
priority. 

As illustrated in Rg. 2. each TSD 19 identifies 

30 the thread's address, execution state, position in 
the dispatch class (by designating the next and 
previous TSDs in the class), and the thread's dis- 
patch class, priority level, and status, i.e., blocked, 
unblocked, suspended, unsuspended. Each TSD 

35 also identifies a next TSD on the run list 32 and a 
previous TSD on the run list to form the run list 32. 

As illustrated in Fig. 3. the DCD identifies a 
"next" DCD to provide the linkage between DCDs, 
and a "current" TSD which is the highest priority 

40 unblocked and unsuspended thread in the dispatch 
class (at the time it is designated as current). The 
current TSD identifies the thread which is elth r 
currently executing on the CPU 14 or currently 
resides on the "run" list 32 waiting for subsequent 

45 execution by the CPU when the CPU is available. 
The DCD also identifies high and low pointers 
which point to the highest and lowest priority 
threads within the dispatch class to provide an 
"anchor" for referencing the dispatch class. 

50 Fig. 4 illustrates chaining of the TSDs. and 

linkage of the DCDs (which is in no particular 
order). All the TSDs within each dispatch class ar 
arranged in a doubly-chained to facilitat reord r- 
ing the list and alt of the DCDs in the syst m are 

55 chained togeth r in a singly-linked mann r. 

Th run list 32 comprises the current thread 
from each dispatch class that is waiting to run on 
the CPU. As illustrated in Fig. 6. the threads are 

5 
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arranged on the run list in priority order with double 
chaining from an anchor 33 which indicates the first 
and last TSD on the run list. If two threads on the 
run list have the same priority, they are positioned 
in order of time of arrival on the run list, later 
arrivals being positioned after earlier arrivals. 

The following describes an embodiment of the 
invention in which only one thread from each dis- 
patch class can be current at any one time; how- 
ever, as described in more detail below in refer- 
ence to another embodiment of the present inven- 
tion, more than one thread from one dispatch class 
can be current at one time and execute concur- 
rently on different CPUs. 

After each thread is created and organized into 
a dispatch class by the ThreadCreate function in 
steps 86 and 88. the ThreadCreate function begins 
the scheduling of the thread by calling a Promote 
primitive function 34 illustrated in Rg. 7. identifying 
th DCD of the dispatch class in which the thread 
resides (step 92 of Rg. 5). Because in this embodi- 
ment of the invention only one thread from each 
dispatch class can be current at any time, decision 
block 98 of Rg. 7 leads to step 100 in which the 
Promote primitive function reads the DCD of the 
id ntified dispatch class to determine if a TSD from 
th dispatch class is designated as current. If so 
(decision block 102). and if the current TSD is 
dispatchable (decision block 1000). then the Pro- 
mote primitive function branches to step 104 to 
queue the current TSD into the run list because in 
th preferred embodiment of the invention, no 
thread in any dispatch class can preempt a current 
thread in the same dispatch class regardless of the 
relative priority levels. Also, no thread in any dis- 
patch class can be queued on the run list while 
another thread from the same dispatch class is 
current. However, if there is not a thread des- 
ignated as current from the identified dispatch 
class, then the Promote primitive function reads the 
TSDs within the identified dispatch class in de- 
scending priority level (the order within the chain) 
to identify the highest priority TSD which is neither 
blocked nor suspended (step 103). If such a thread 
exists, (decision block 1001) it becomes the current 
TSD and the Promote primitive function calls a 
Schedule primitive function 36 and identifies the 
current thread (step 104). The Schedule primitive 
function 36 determines if the thread is already on 
the run list (decision block 105 of Rg. 8). If not, the 
Schedul primitive function reviews the priority lev- 
els of the other (if any) TSDs on th run list (step 
106). and qu u s the TSD of th current thread 
onto th run list in priority ord r relative to the 
current threads from the oth r dispatch class s 
which are already on the run list (step 108). The 
Schedul primitive function then returns to the call- 
er, in this case the Promote primitive function (step 



110). In response, the Promot primitive function 
updates a current thr ad count described in more 
detail below (step 150). and then retums to its 
caller, the ThreadCreate function. Next, the Thread- 

5 Create function calls the Promote primitive function 
identifying the DCD of the thread which called the 
ThreadCreate function (step 94) and the steps of 
Rgs. 7 and 8 are repeated for this other dispatch 
class. Thus, from each dispatch class which does 

10 not already have a current TSD identified, the op- 
erating system selects the highest priority unblock- 
ed and unsuspended thread (TSD). denotes the 
thread (TSD) as the current thread, and queues the 
TSD onto the run list 32. If the dispatch class has 

75 no threads which are available for execution 
(unblocked and unsuspended). then the dispatch 
class is not represented on the run list. 

Because the run list is now changed, it is 
possible that a thread on the run list has a higher 

20 priority than the currently executing thread. There- 
fore, all the threads in the run list are now permit- 
ted to contend for the CPU. Accordingly, the 
ThreadCreate function calls the Switch primitive 
function 46 to initiate execution of the highest prior- 

25 ity TSD on the run list (step 116). The first step of 
the Switch primitive function is to determine if a 
thread is currently executing on the CPU (decision 
block 119 of Rg. 9). If so, the Switch primitive 
function saves the execution state of the currently 

30 executing thread by copying the contents of the 
associated CPU registers into the currently-execut- 
ing thread's TSD (step 120). These registers in- 
dicate the program step at which the program 
thread was halted, and the locations of stored data 

35 associated with the program thread. This state in- 
formation will be necessary to resume execution of 
the program thread at a later time. If there was no 
thread currently executing on the CPU when the 
Switch primitive function was called, then decision 

40 block 119 avoids step 120. 

Next the Switch primitive function calls an Un- 
schedule primitive function 38 to remove the TSD 
of the highest priority thread from the run list. 
Because of step 108 of the previously called 

45 Schedule primitive function, said highest priority 
thread is necessarily the first thread on the run list. 
After verifying that the TSD is actually on the run 
list (decision block 256 of Fig. 13). the Unschedule 
primitive function removes it from the run list by 

50 changing the chain pointers between the run list 
anchor and the second highest priority thread on 
the run list to point to each other, omitting the 
highest priority TSD (step 257), Then, th Un- 
schedul primitive function returns to the caller 

55 (step 259), and th Switch primitive function r - 
stores the execution state of the thread obtained 
from the run list into the CPU regist rs (step 124), 
causing the CPU to resume executing the thread at 
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the point where the CPU left off processing the 
thread during its last period of execution (step 
128). If this is the first instance in which th highest 
priority thread has been executed or dispatched, 
then the thread is executed fronn its beginning. 

The foregoing example illustrates that a thread 
may continue to run on a CPU until it is preempted 
by a higher priority program thread from a different 
dispatch class. The preemption can occur at any 
time that the Promote and Switch primitive func- 
tions are called. The Promote and Switch primitive 
functions can be called even when the currently 
executing thread is dispatchable. However, if the 
highest priority thread in the system is from the 
same dispatch class as the one that is currently 
executing on the CPU (due to this highest priority 
thread being created or made available after the 
currently executing program thread began execu- 
tion), then this highest priority thread will not be 
queued onto the run list unless and until the cur- 
rently executing thread Is blocked, is suspended by 
itself or another program thread or is deleted. This 
provides coordination between threads within the 
same dispatch class in accordance with an object 
of the present invention. 

An executing thread blocks itself when it must 
wait for some condition to become satisfied before 
it can continue. This will permit another dispatcha- 
ble thread from the same or different dispatch 
class to execute, and thereby make optimum use 
of the CPU. For example, if the currently executing 
program thread calls a routine implementing op- 
erating system services to obtain data from a 
queue and the data is not available, the operating 
system service routine, which is executing on the 
currently executing program thread, is programmed 
to block the currently executing program thread in 
the following manner. The operating system ser- 
vice routine places itself onto a list of threads 
waiting on the queue, and then calls a Block primi- 
tive function 45 within the operating system to 
block its own thread. In response, the Block primi- 
tive function 45 sets a block status field in the 
currently executing program thread's TSD (step 
172 of Rg. 10), and then updates the currently 
executing program thread's DCD to indicate that 
there is no current thread in the dispatch class 
(step 174). Then, the Block primitive function calls 
the Promote primitive function for the dispatch 
class of the newly blocked thread (step 176). De- 
cision block 102 of the Promote primitive function 
indicates that th re is now no current thread for this 
dispatch class so one should be selected, if avail- 
able, in step 103 to replace the blocked thread. 
Thus, the Promote primitive function, in conjunction 
with the Schedul primitive function 46 that it calls 
in step 104, qu ues the high st priority program 
thread, if any. which is unblocked and unsusp n- 
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ded from th dispatch class onto the run list. How- 
ev r. because th currently xecuting program 
thread is now blocked, it cannot be a candidate for 
currency and cannot be copied onto the run list 
5 regardless of its priority level. Next, the Block 
primitive function 44 calls the Switch primitive func- 
tion 46 to select the highest priority thread on the 
run list for execution by the CPU in the manner 
noted above. Because the TSD of the currently 
10 executing thread is not now on the run list, it 
cannot be selected for subsequent execution and 
will be removed from the CPU in step 120. It is 
possible that another thread from the same dis- 
patch class as the blocked one will be the highest 
75 priority thread on the run list and execute. 

If another thread subsequently generates data 
for the queue, it will examine the list of program 
threads waiting for the data on the queue. Th n. 
the thread which generated the data will remov 
20 the waiting thread from the queue wait list, and 
unblock the waiting thread by calling an Unblock 
primitive function 48, identifying the TSD of the 
blocked, waiting thread. In response, the Unblock 
primitive function changes the waiting thread's TSD 
25 indicator to remove the block notation (step 207 of 
Rg. 11). and determines the dispatch class in 
which the now unblocked waiting thread's TSD 
resides by examining the unblocked thread's TSD 
(which contains a pointer to the DCD) (step 208). 
30 Then, the Unblock primitive function calls the Pro- 
mote primitive function (step 210) identifying the 
DCD of the now unblocked thread to copy this 
thread or a higher priority unblocked and un- 
suspended thread from the same dispatch ^class 
35 onto the run list if the dispatch class has no current 
thread at this time. After receiving the return from 
the Promote primitive function, the Unblock primi- 
tive function 48 determines the dispatch class of 
the thread which generated the data (step 212). 
40 and calls the Promote primitive function 34 to pro- 
mote the dispatch class of the thread which gen- 
erated the data (step 21 4). After the Promote primi- 
tive function 34 returns to the Unblock primitive 
function, the Unblock primitive function calls th 
45 Switch primitive function 46 (step 220) to execute 
the highest priority thread which is either on th 
run list or on the CPU, in the manner noted abov , 
After the Switch primitive function retums to the 
Unblock primitive function, the Unblock primitive 
50 function returns to its caller, the data generating 
thread (step 221). 

As noted above, th Block primitiv function 
can be called by a s rvic routine which is ex cut- 
ing on th currently executing thread when the 
55 thread must wait for ia r source to become avail- 
abl or some other vent to occur. A thread can 
also b "suspended" by itself or another thread to 
halt or prevent execution of the thread. The thread 

7 
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which is the target of the suspension can currently 
be executing on the CPU. reside on the run list or 
reside elsewhere within a dispatch class and have 
blocked or unblocked status. A suspension can be 
used to cause a sharing of the CPU by other 
thr ads that have the same or lower priority or for 
other purposes. For exannple, a thread which up- 
dates a video screen can be suspended to 
"freeze" the frame. 

Each TSD includes a "suspend counter" field 
which indicates the number of program threads 
which have requested suspension of the target 
thr ad represented by the TSD. If the counter is 
greater than zero, then the thread indicated by the 
TSD is suspended. 

When a program ("suspending") thread wants 
to suspend a target thread, the suspending thread 
calls a ThreadSuspend function 50 illustrated in 
Fig. 12 with an identification of the target thread. 
First, the ThreadSuspend function increments the 
suspend counter of the target thread's TSD (step 
252). If the suspending thread is not suspending 
itself (decision block 253). the ThreadSuspend 
function determines whether the target thread is in 
the same dispatch class as the suspending thread 
(decision block 254). If so. the ThreadSuspend 
function calls an Unscheduie primitive function 
(Step 255) to remove the target thread from the run 
list if it is on the run list (decision block 256 and 
step 257 of Fig. 13). The Target thread could only 
be on the run list in a co-scheduling, multiproces- 
sor embodiment of the present invention as de- 
scribed in more detail below. If the target thread is 
not in the same dispatch class, decision block 254 
leads to decision block 258 in which the Thread- 
Suspend function determines if the target thread is 
currently executing on a CPU (again, in a mul- 
tiprocessor embodiment). If not. the Thread- 
Suspend function 50 calls the Unscheduie primitive 
function 38 identifying the target thread to remove 
the target thread from the run list if the target 
thread is on the run list (step 259). After receiving 
the return, the ThreadSuspend function determines 
if the target thread is current in its class (decision 
block 264), and if so changes the current TSD field 
in the target thread's DCD to indicate that no 
thread is current (step 260). Next, the Thread- 
Suspend function calls the Promote primitive func- 
tion 34 to promote the dispatch class of the target 
thread (step 261). Because the target thread is now 
suspended, the next highest priority thread within 
the targ t thread's dispatch class that is not bloc- 
ked or suspended will become current. Then, the 
Promote primitive function calls the Schedule 
primitive function to copy the new current thread 
from the suspended thread's dispatch class onto 
the run list. After receiving the return from the 
Promote primitive function, the ThreadSuspend 



function 50 calls the Promote primitiv function to 
promote the dispatch class of th suspending pro- 
gram thread because the new thread from the 
target thread's dispatch class may possess a high- 
5 er priority (step 262). Then, the ThreadSuspend 
function calls the Switch primitive function (step 
263). 

Referring again to decision block 253. if the 
suspending thread is suspending itself, the Thread- 

70 Suspend function calls the Unscheduie primitive 
function to remove its TSD from the run list. N/Vhile 
the ThreadSuspend function's TSD should not be 
on the run list, this step is a safeguard (step 265). 
Next, the ThreadSuspend function changes the cur- 

T5 rent TSD field in its own DCD to indicate that no 
thread is current (step 266), promotes its own class 
(step 267), and calls the Switch primitive function 
(step 268). 

Because a suspended thread cannot run, it 
20 cannot decrement its own suspend counter field 
and therefore must rely on another program thread 
to decrement the suspend counter field. When this 
other thread, running on CPU 14, desires to re- 
sume the suspended thread, this other thread calls 

25 a ThreadResume function 52. identifying the sus- 
pended thread. In response, the ThreadResume 
function 52 decrements the suspend counter field 
of the suspended program thread's TSD (step 302 
of Fig. 14). If the count value is still greater than 

30 zero (decision block 304). then the ThreadResume 
function 52 returns to the currently executing pro- 
gram thread (step 306). However, if the suspend 
counter field now exhibits a count of zero, then the 
ThreadResume function 52 calls the Promote 

35 primitive function 34 to promote the dispatch class 
of the previously suspended thread and thereby 
give the resumed thread a chance to become cur- 
rent (step 308). After receiving the return, the 
ThreadResume function 52 calls the Promote 

40 primitive function to promote the dispatch class of 
the currently executing program thread (step 310). 
Because the resumed thread may be of higher 
priority than the resuming thread. the 
ThreadResume function 52 calls the Switch primi- 

45 tive function 46 (step 312) to execute the highest 
priority thread on the run list or CPU, in the manner 
described above, and then returns to the caller 
(step 306). 

It should be noted that at any time, a currently 
50 executing program thread can be preempted by 
another, higher priority thread within another dis- 
patch class pursuant to a Promote and Switch call 
made by any of the other functions 15, 48. 50. 52 
and 60. 

55 When a thread completes xecution, it can 

either call a ThreadDelete function 60 directly or 
return to the operating system which will call the 
ThreadDelete function. In response to the call, the 
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Thr adDelete function 60 locates the target 
thread's TSD (step 400 of Rg. 15). and then deter- 
min s if the calling thread is del ting itself 
(decision block 401). If so, the ThreadDelete func- 
tion determines if the deleting/target thread initiated 
the deletion (or as described below, another thread 
forced the thread to call the ThreadDelete function) 
(decision block 402). If another thread initiated the 
deletion, then the ThreadDelete function waits for 
the initiating thread to block itself (step 403) and 
then calls all kernel subsystenns that require no- 
tification of the deletion of the thread (step 404). 
Next, the ThreadDelete function removes the target 
TSD from the dispatch class in which it resides 
(step 408). If the dispatch class is now empty 
(decision block 410). then the ThreadDelete func- 
tion deallocates the DCD as well (step 412). If the 
dispatch class is not empty, then the ThreadDelete 
function calls the Promote primitive function for the 
target thread's dispatch class to permit another 
thread from the target thread's dispatch class to 
become current (step 414). After receiving the re- 
turn, the ThreadDelete function removes the target 
thread's TSD from a list of threads that comprise 
the associated process (step 415). If the deleted 
thread initiated the deletion (decision block 416). 
then the ThreadDelete function calls the Switch 
primitive function to execute another thread (step 
418). However, if another thread initiated the dele- 
tion, then the ThreadDelete function resets the 
block indicator in the initiating thread's TSD and 
calls the Promote primitive function to operate on 
the initiating thread's dispatch class before calling 
the Switch primitive function. 

Referring again to decision block 401. If the 
thread targeted for deletion is not the calling 
thread, but instead, the target thread is executing 
on some CPU or is not current (decision block 
468), then the ThreadDelete function stores the 
identity of the deleting thread in the TSD of the 
target thread (step 419), changes the status of the 
target thread to unblocked and unsuspended, if it 
was blocked or suspended, respectively (step 420). 
and changes the execution state of the target 
thread such that the field which normally indicates 
where the target thread shall resume execution 
instead indicates the location of step 400 of the 
ThreadDelete function (step 421). Next, the Thread- 
Delete function unschedules the target thread (step 
422) and boosts the priority of the target thread. 

Next, the ThreadDelete function calls the Pro- 
mot primitive function for th dispatch class of the 
target thread (step 424) and then boosts th prior- 
ity of the calling thread for fast completion (step 
(425). N xt. th ThreadDelete function calls th 
Block primitive function 45 to block itself awaiting 
completion of the deletion (step 428) and then 
restores the priority of the calling thread (step 429). 
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The effect of steps 420-428 is to cause the target 
thread to proce d to the CPU for x cution soon. 
When xecution b gins, the CPU proceeds to x- 
ecute steps 404-418 described above, the only 
5 additional consideration being that the target thread 
must unblock the deleting thread prior to deleting 
itself. 

Operating system 10 also includes a Thread- 
SetPriority function 55 which can be called to ad- 
10 just the priority of a thread. In response to the call, 
the Thread Set Priority function sets a parameter 'f 
equal to zero (step 501 ) and then determines if the 
target thread is on the run list (decision block 503). 
If so, the ThreadSetPriority function increments th 
75 parameter T (step 505). Next the function exam- 
ines T (decision block 507) and unschedules the 
target (step 509) if f = 1. Next, the ThreadSet- 
Priority function changes the priority field of th 
TSD to the level specified by the caller (step 511). 

20 and if the thread was on the run list (decision block 
512), schedules the target (step 513). schedul s 
the caller (step 515) and calls the Switch primitive 
function (step 517). 

Operating system 10 also includes a Thread- 

25 SetDispatchClass function 53 which is illustrated in 
Rg. 17 and can be called to place the calling 
thread in a dispatch class by itself or place another 
thread in the same dispatch class as the calling 
thread (decision block 600). In the former case, th 

30 ThreadSetDispatchClass function removes the call- 
ing thread from the calling thread's current dis- 
patch class by changing the chain pointers (step 
602). calls the Promote primitive function for this 
current dispatch class (step 604). creates a new 

35 dispatch class (step 606). places the calling 
thread's TSD in the dispatch class by changing th 
chain pointers (step 608). calls the Promote primi- 
tive function for the new dispatch class (step 610). 
and finally calls the Switch primitive function (step 

40 612). In the latter case, the ThreadSetDispatch- 
Class function removes the target thread from th 
target thread's current dispatch class (step 614), 
calls the Promote primitive function for this current 
dispatch class by changing the chain pointers (step 

45 616). removes the target thread's TSD frorh the run 
list (if it is queued there) by calling the Unschedule 
primitive function (step 618), adds the target 
thread's TSD to the calling thread's dispatch class 
(step 620), calls the Promote primitive function for 

50 the calling thread's dispatch class (step 622), and 
finally calls the Switch primitive function (step 612). 

Operating system 10 also includes a 
ThreadYield function 61 which allows a curr ntly 
executing program thread to relinquish control of 

55 the CPU without blocking or susp nding itself or 
otherwise becoming non-dispatchable. The current- 
ly executing thread can call the ThreadYield func- 
tion to request that a specific thread in its class. 
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indicating by a thread ID, be made cunrent or that 
th high st priority available thread in its dispatch 
class (which may still be itself) b made current. In 
th later cas . the call to the ThreadYield function 
is intend d to permit th most important work 
(thread) from the dispatch class to be executed. 
However, in ith r case, the call to the ThreadYield 
function will not guarantee that the specified thread 
or the highest priority dispatchable thread in the 
dispatch class is executed immediately, only that 
th selected thread be immediately made current. 
An application program developer may code a call 
to the ThreadYield function at any point in the 
program thread where another thread in the same 
dispatch class should execute. For example, if a 
program thread is long running and there is a 
likelihood that another higher priority thread will be 
made available during the execution of the long 
running thread, the long running thread may in- 
clude a call to the ThreadYield function. 

Fig. 18 illustrates the ThreadYield function 61. 
Aft r receiving the call, the ThreadYield function 
determines if the call specifies a particular (target) 
program thread in the same class to be made 
current (decision block 700). If so. the ThreadYield 
function verifies that the target thread is in the 
same dispatch class (decision block 702) and that 
th target thread is available or dispatchable 
(d cision block 704). If both of the verifications are 
true, then the ThreadYield function sets the current 
thread field of the corresponding DCD to indicate 
th TSD of the target thread (step 706), promotes 
the class of the target thread (step 708) and then 
calls the Switch primitive function (step 710). Thus, 
the specified target thread will be promoted to the 
run list, the currently executing thread will be re- 
moved from the CPU because it is not on the run 
list when the Switch primitive function was called, 
and the highest priority thread on the run list will 
be executed. This highest priority thread on the run 
list may or may not be the target thread. 

Referring again to decision block 700. if the 
call to the ThreadYield function does not specify a 
particular target thread, then the ThreadYield func- 
tion sets the current thread field of the DCD to zero 
(step 712) and then jumps to 708 and 710 to 
promote the class and call the Switch primitive 
function, respectively. Thus, the highest priority 
available thread in the dispatch class is queued 
onto the run list and contends for the CPU. If the 
thread which called the ThreadYield function has 
th highest priority, th n it will be made current 
b caus this thread is still available. 

The pr sent invention can also utilize multiple 
CPUs 14a, b, c to xecute multipl program 
threads concurrently. To use multiple CPUs, it is 
necessary to ensure that only one CPU can ma- 
nipulate a particular data structure (TSD, DCD or 



run list) at any on time. Otherwise, an invalid data 
structure could result. Consequ ntly. when a pro- 
gram thread running on one CPU wants to manipu- 
late a data structur . th program thr ad acquir s 

5 or sets a lock associated with th data structur . A 
well-known compar and swap instruction is us d 
to obtain a lock in on instruction cycle to avoid 
race conditions. No other program thread running 
on another CPU can manipulate the data structure 

70 until the lock is reset by the program thread which 
set it. For read mode operation, the lock is iden- 
tified as read mode which allows other program 
threads to read but not update the data structure. 
For write mode operation, the lock is identified as 

rs write mode which prohibits other readers or writers 
from accessing the locked data structure. These 
types of locking arrangements are well known in 
the art. In the embodiment illustrated in Fig. 1, 
there is one "thread" lock for all TSDs and DCDs. 

20 and another for the entire run list. As a result, when 
a program thread running on any CPU obtains 
control of the thread lock for any of these types of 
data structures, then no other program thread run- 
ning on any CPU can manipulate any of the data 

25 structures. 

A lock is required for the foregoing functions 
45. 48. 50. 52 and 60, and is maintained until the 
associated primitive functions 34. 36. 38 and 46 are 
completed. 

30 In the multiprocessor operation, all of the func- 
tions and primitive functions are executed as de- 
scribed above except for the Switch. Suspend and 
ThreadDelete functions. 

Whenever the Switch primitive function 46 is 

35 called by a function or primitive function executing 
on one of the CPUs, the Switch primitive function 
responds by providing the highest priority thread 
from the run list for execution by the CPU of the 
calling thread. As a result, multiple threads from 

40 the run list can be executed concurrently by mul- 
tiple (N) CPUs 14. To guarantee that each of the N 
CPUs 14 will always have a thread to execute, the 
system maintains an extra set of N dispatch 
classes, each of which contains exactly one "null" 

45 thread of lowest priority. Each time they are dis- 
patched, these threads are programmed to cause 
the CPU to become idle until they are interrupted 
by another CPU as described below, after which 
they call the Promote and Switch primitive func- 

50 tions to obtain a productive thread for the CPU to 
execute in place of the null thread. 

There is the additional concern that the targ t 
thread of the Suspend or ThreadDel te functions 
may be currently executing on another CPU when 

55 it is desired to suspend or delete the target thread. 
It is necessary to stop the suspending thread from 
execution until it is certain that the target thread is 
no longer executing. Thus, the ThreadSuspend 

10 
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function examines a processor ID field in the TSD 
of the target thread to determine if the targ t thread 
is curr ntly executing (decision block 258 of Fig. 
12). If not, the ThreadSuspend function suspends 
the target thread as noted above for the single 5 
processor environment. However, if the target 
thread is currently executing In a multiprocessor 
embodiment, then the ThreadSuspend function 
s nds an interrupt to the target thread's CPU to call 
the Switch primitive function (step 272). In re- io 
sponse, the target thread's CPU runs interrupt code 
which calls the Switch primitive function. The 
ThreadSuspend function waits on the processor ID 
field of the target TSD to indicate that the target 
thread is no longer executing (step 274). Then, the is 
ThreadSuspend function proceeds to step 259 to 
continue processing as described above. 

When the ThreadDelete function is called in a 
multiprocessor environment, the ThreadDelete 
function determines if the target thread is currently 20 
executing on another CPU by reading the proces- 
sor ID field of the TSD (decision block 468 of Fig. 
15). If so. the ThreadDelete function sends an 
interrupt to the target thread's CPU (step 470). The 
interrupt includes a request for the target thread to 25 
block itself. The Interrupt handler is programmed to 
comply with the request by calling the Block primi- 
tive function. Meanwhile, the ThreadDelete function 
waits on the processor ID field of the target 
thread's TSD (step 472). After the target thread has 30 
been blocked, the ThreadDelete function continues 
at step 404 described above. 

The foregoing mode of operation utilizing mul- 
tiple processors 14a-c permits only one thread 
from each dispatch class to run at any one time. 35 
This allows multiple threads from separate dispatch 
classes to run concurrently on multiple CPUs while 
respecting the preemption rules that apply within 
each dispatch class. However, another mode of 
operation of the present Invention permits multiple 40 
program threads from the same dispatch class to 
run concurrently. In this mode of operation, when 
an application program creates a dispatch class, 
the application program designates the maximum 
number of program threads from the dispatch class 45 
which are permitted to run concurrently. This maxi- 
mum number is stored as a "max current thread 
no." field in the DCD (Rg. 3). The DCD also 
includes a list of current TSDs. the number of 
current threads and an anchor for all of the threads. so 
After a change which affects the dispatch class, for 
example, a call to the ThreadCreate, Block, Un- 
block, Suspend. Resum or ThreadDelete function, 
the Promote primitive function is called which pro- 
ceeds to read from the DCD the maximum current 55 
thread number, the number of current threads, and 
the list of current threads (decision block 98 and 
step 140 of Fig, 7). If there are fewer current 



threads than the maximum current thread number, 
(decision block 142), then the Promote primitiv 
function 34 sel cts on or more additional un- 
blocked and unsuspended program threads of th 
highest priority to make current such that the total 
number of current threads will equal the maximum 
current thread number (step 144). Next, as noted 
above, the Promote primitive function 34 calls the 
Schedule primitive function 36 in step 104 (once 
for each additional thread) to copy these additional 
TSDs onto the run list. Finally, the Promote primi- 
tive function 34 upxlates the number of current 
threads field to equal the number of current threads 
(step 150), and returns to the caller (step 112). 

In another implementation of operating system 
10 it is possible to characterize each dispatch class 
by both a minimum and a maximum processor 
count. The minimum processor count defines th 
minimum number of processors that must be avail- 
able for threads in the class to be dispatched and 
such threads would then execute simultaneously; 
no member of the class is allowed to run unless 
that minimum number of processors is available for 
the threads of that class. The maximum processor 
count specifies the maximum number of proces- 
sors on which members of the class will be allowed 
to run simultaneously, and thus limits the degree of 
parallel execution of the threads in the class. When 
the maximum processor count is one. the members 
of the class behave like "co-routines" with explicit 
sequencing; when the minimum processor count is 
equal to the size of the class, the c\ass may be 
viewed as a "task force" with guaranteed co- 
scheduling. 

The following fields are added to each DCD to 
implement minimum and maximum processor 
count attributes: 

m - minimum processor count for this class: 
M - maximum processor count for this class; 
X - number of threads from this class cur- 
rently executing; 
s - numfc>er of threads from this class on the 

(session) run list 32; and 
c - number of threads on a class run list 
798 for this class. This class run list is 
an additional run list which is structured 
similarly to run list 32 and serves as a 
staging ground for collection of TSDs 
from a dispatch class whose minimum 
processor count is greater than one. The 
TSDs are collected on th class run list 
until the minimum processor count of 
threads is promoted and scheduled onto 
the session run list. 
The constraints on the possibi values of th 
above variables and parameters are as follows: 
1 < = m < = min(M. number of processors); 
either x = 0orm<= x< = M; 
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if X = 0. then eith rs = Oorm<=s<=M: 
if X > 0. then 0 < = s < = M-x; 
if X = 0 and s = 0. then 0 < = c < m; and 
if 0 < s < M-x. then c = 0. 

To begin the process of queueing a TSD on its s 
class run list for a dispatch class with a minimum 
processor count greater than one, the Promote 
primitive function is called. In this implementation 
of operating system 10. step 98 of Fig. 7 leads to 
step 140 because the maximum current no. field io 
should equal the maximum processor count and is 
greater than one. Then the DCD is read in step 140 
and decision block 142 follows. In decision block 
142 the question is whether there are fewer current 
threads than the maximum processor count, and 75 
"current threads" means threads on the session 
run list plus threads which are chained from the 
session run list as described below plus the 
threads on the class run list. If there are fewer 
current threads than the maximum processor 20 
count, then additional available threads are iden- 
tified as being current (step 144). Then the 
ModifiedSchedule primitive function 53 illustrated in 
Fig. 19 is called (step 143) instead of the original 
Schedule primitive function for each additional 25 
available thread. 

In decision block 802, the ModifiedSchedule 
primitive function determines if x = 0 and s = 0, i.e. 
if there are no threads from the dispatch class 
either executing on a CPU or queued on the ses- 30 
sion run list 32. If x = 0 and s = 0, then the Modified- 
Schedule primitive function queues one of the 
available TSDs onto the class run list 798 (step 
804) and increments the parameter c (step 806). If 
the number of TSDs on the class run list is less 35 
than the minimum processor count, decision block 
808 leads to the end of the ModifiedSchedule 
primitive function. As noted above, for each thread 
in the dispatch class which is available for execu- 
tion, the Promote primitive function calls the 40 
ModifiedSchedule primitive function, and for the 
first m-1 of these TSDs, steps 802-806 are re- 
peated. For the next TSD which is scheduled by 
th ModifiedSchedule primitive function, decision 
block 808 leads to step 810 in which the Modified- 45 
Schedule primitive function represents the class 
run list 798 on the session run list 32 as described 
below (step 810), and sets the parameter s equal to 
c (step 812) and the parameter c equal to zero 
(step 814), to reflect this representative transfer 50 
from the class run list to the session run list. 

After one TSD from the class run list is queu d 
onto the session run list or on or more of such 
TSDs begin to execute, and anoth r TSD is pro- 
moted, decision block 802 I ads to decision block 55 
816 in which the ModifiedSchedule primitive func- 
tion determines if the number of ex cuting threads 
(if any) from this dispatch class plus the number of 



threads from this dispatch class on the session run 
list are less than the maximum processor count. If 
so, the ModifiedSchedul primitive function queues 
this latest TSD directly onto the session run list 32 
(step 818) and increments the parameter s to re- 
flect this queueing (step 820). Steps 818 and 820 
are repeated for each additional TSD which is 
promoted from the same dispatch class until the 
number of executing threads and threads on the 
session run list from this dispatch class equal the 
maximum processor count. 

Subsequently promoted TSDs (after the maxi- 
mum processor count is attained) are queued onto 
the class run list (step 822), and the parameter c is 
incremented (step 824). 

The way the TSDs from the class run list are 
represented on the session run list in steps 810 
and 822 depends on the values of x and s. as 
follows: 

a. If X = 0 and s = m. then only the lowest 
priority of the m runnable TSDs appears on the 
run list; the remaining m-1 TSDs are chained 
from it. This configuration is the result of step 
810 described above. The chained TSDs are 
considered part of the session run list and the 
Switch primitive function considers these 
chained TSDs for execution. When this lowest 
priority thread is the highest priority thread on 
the run list and a CPU becomes available for it. 
then the other m-1 higher priority threads which 
are chained from the representative preempt m- 
1 other executing threads which have a lower 
priority. 

b. If x = 0 and s > m, then the first m TSDs are 
represented as above by the lowest priority of 
the m priority TSDs. and the remaining s-m 
TSDs, whose run list position is behind the m-th 
TSD. are queued directly on the session run list. 
Each of these remaining s-m TSDs will be di- 
rectly queued on the session run list in step 61 8 
after the representative if their priority level is 
below that of the m-th TSD. 

c. If X > = m. then up to M-x TSDs from the 
class may appear on the session run list in 
priority order. 

A class is dispatched at the point when its m-th 
thread comes to the top of the run list. At that 
point, three cases arise: 

1) There are m idle processors available, in 
which case the m TSDs can be run immediately 
on th se m processors. 

2) There are Km idl processors and p = m-i 
other processors running threads of lower prior- 
ity than the m highest priority thread of the class 
that require dispatching, in this case, the ex cut- 
ing threads on the other processors can be 
preempted to let the m threads of the new class 
run. 
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3) The number of idle and preemptable proces- 
sors is insufficient to run the class. Th Switch 
primitive function described abov can b modi- 
fied to handle this deficiency by implementing 
either of the following four options: 

a. Refuse to dispatch any other TSD, even 
one of higher priority that subsequently be- 
comes dispatchabte. until it has first dis- 
patched the waiting class. 

b. Refuse to dispatch any lower priority TSD 
now, but resume normal dispatching rules if a 
higher priority TSD subsequently becomes 
dispatchable. 

c. Attempt to dispatch a lower priority TSD 
now. with the intention of being able to pre- 
empt it whenever enough other processors 
become available, and resume normal dis- 
patching rules if a higher priority TSD subse- 
quently becomes available. 

d. Dispatch only lower priority TSDs (which 
can later be preempted) until the ready class 
has been dispatched. 

The other requisite modification to the Switch 
primitive function is to halt execution of the entire 
class whenever the number of executing threads is 
about to drop below m. This is implemented by 
tracking the number of threads which are removed 
from the CPUs pursuant to calls to the Switch 
primitive function. 

It should also be noted that the use of the class 
run list may optimize the Promote primitive func- 
tion when the minimum processor count and maxi- 
mum processor count both equal one. because the 
class run list contains only available threads and its 
use avoids repeated searches through the dispatch 
class for available threads. 

Based on the foregoing, an operating system 
according to the present invention has been dis- 
closed. However, numerous substitutions and modi- 
fications can be made without deviating from the 
scope of the present invention. Therefore, the in- 
vention has been disclosed by way of illustration 
and not limitation, and reference should be made 
to the following claims to determine the scope of 
the invention. 

Claims 

1. A multitasking operating system comprising: 

means for assigning a multiplicity of program 
threads to a plurality of classes such that at 
least one of said classes can be assign d a 
plurality of program threads; 

means for assigning priority levels to said pro- 
gram threads; and 



means for scheduling execution of said pro- 
gram threads such that a program thread from 
another class can preempt execution of a low- 
er priority program thread from said one class. 

5 but a program thread in said one class having 

a higher priority than said lower priority pro- 
gram thread in said one class cannot preempt 
or is more restricted than said program thread 
in said other class in preempting execution of 

^0 said lower priority program thread in said one 

class. 

2. A multitasking operating system as set forth in 
claim 1 

75 

wherein the scheduling means prevents said 
program thread in said one class from pre- 
empting said lower priority program thread in 
said one class while said lower priority pro- 
20 gram thread is dispatchabte. 

3. A multitasking operating system as set forth in 
claim 2 wherein the scheduling means permits 
said program thread from said other class to 

25 preempt said lower priority program thread 

from said one class while said lower priority 
program thread is dispatchable. 

4- A multitasking operating system as set forth in 
30 claim 1 wherein the means for assigning pro- 

gram threads into classes and the means for 
assigning priority levels to the program threads 
is based on parameters specified by applica- 
tion programs. 

35 

5. A multitasking operating system as set forth in 
claim 1 further comprising means for selecting 
an available program thread from each of said 
classes for current or subsequent execution, 

40 said selections being based at least in part on 

relative priorities of the program threads within 
each class. 

6. A multitasking operating system as set forth in 
45 claim 2 further comprising means for selecting 

at least two program threads for execution 
from said one class which can be executed 
concurrently on a like number of processors. 

50 7. A multitasking operating system as set forth in 
claim 1 furth r comprising means for selecting 
a program thread from each class for ex cu- 
tlon by a processor, and means for prev nting 
the selected program thread from each class 

55 while executing from being replaced for execu- 

tion by another program thr ad from the sam 
class until th selected program thread exper- 
iences a non-dispatchable condition. 
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a A multitasking op rating system as set forth in 
claim 5 further comprising means for queueing 
the selected prograni thread from each class 
onto a run list for subsequent execution by one 
or more processors, and selecting the highest 
priority program thread ori the run list for ex- 
ecution by the next available processor. 

9. A multitasking operating system as set forth in 
claim 8 further comprising means for compar- 
ing priority of a program thread which is cur- 
rently executing on a processor to a highest 
priority program thread on the run list that is 
awaiting execution, and switching execution to 
the highest priority, waiting thread in the run 
list if the highest priority thread on the run list 
has a higher priority than the currently execut- 
ing program thread. 

10. A multitasking operating system as set forth in 
claim 6 wherein said one class includes at 
least three program threads and said at least 
two selected program threads have the highest 
priority levels of all program threads in said 
one class which are available for execution. 

11. A multitasking operating system as set forth in 
claim 4 further comprising means for designat- 
ing a maximum number of program threads to 
be run concurrently from said one class on 
different processors. 

12. A multitasking operating system as set forth in 
claim 1 further comprising means, initiated by 
a currently executing program thread, for bloc- 
king said currently executing program thread 
from further execution. 

13. A multitasking operating system as set forth in 
claim 12 wherein said currently executing pro- 
gram thread initiates the blocking if a request 
of said currently executing program thread 
cannot be satisfied or an operation of said 
currently executing program cannot be com- 
pleted, due to a condition beyond control of 
said currently executing program thread. 

14- A multitasking operating system as set forth in 
claim 12 further comprising means, responsive 
to the blocking means, for selecting the high- 
est priority thread from the class containing the 
blocked program thread for immediate or sub- 
sequent execution. 

15. A multitasking operating system as set forth in 
claim 1 furth r comprising means, initiated by 
a currently executing program thread, for sus- 
pending another program thread in the same 
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25 



30 



35 



40 



or differ nt class, wher by th suspended pro- 
gram thread is made unavailable for execution. 

16. A multitasking operating system as set forth in 
claim 15 further comprising means, initiated by 
a program thread other than said suspended 
program thread, for terminating the suspension 
of said suspended program thread. 

17. A multitasking operating system as set forth in 
claim 1 further comprising means, initiated by 
one currently executing program thread, for 
suspending another program thread. 



18. A murtitasking operating system as set forth in 
claim 1 further comprising means for a dis- 
patchable, executing program thread to volun- 
tarily suspend execution of itself to permit an- 
other program thread which may be in the 

20 same dispatch class to be executed. 

19. A method for operating a computer, said meth- 
od comprising the steps of: 



45 



50 



assigning a multiplicity of program threads to a 
plurality of classes, each class t>eing assigned 
at least one program thread, and at least one 
class being assigned a plurality of program 
threads; 

executing one of the program threads from 
said one class; 

preventing another one of the program threads 
in said one class from preempting execution of 
said one program thread from said one class 
while executing said one program thread from 
said one class; and 

after executing at least part of said one thread 
from said one class, preempting execution of 
said one program thread from said one class 
with a program thread from another class. 

20. A method as set forth in claim 19 further 
comprising the step of preventing any program 
thread in any class from preempting any other 
program thread in the same class during ex- 
ecution of said other program thread. 



21. A method as set forth in claim 19 further 
comprising the step of assigning a priority lev- 
el to each of said program threads to form a 
basis for preemption, and wherein said pro- 
55 gram thread from said other class has a higher 

priority level than th preempted program 
thread from said one class. 
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22. A method as set forth in claim 21 furth r 
comprising th step of queueing th high st 
priority I vel program thread which is avallabi 
for execution from each class on a run list for 
subsequent execution by one or more proces- s 
sors. 

23- A method as set forth in claim 22 further 
comprising the step of executing the highest 
priority program thread on the run list k>efore ro 
executing the other program threads on the 
run list. 

24. A method as set forth in claim 23 further 
comprising the steps of: 75 

blocking execution of a currently executing 
program thread; and 

after the blocking step, selecting for subse- 20 
quent execution the highest priority program 
thread which is not blocked and otherwise 
available for execution, from the class contain- 
ing the blocked program thread. 

25 

25. A method as set forth in claim 19 further 
comprising the step of suspending another 
program thread in the same or different class, 
whereby the suspended program thread is not 
available for execution. 30 

26. A method as set forth in claim 19 further 
comprising the step of suspending said one 
program thread, the suspension being done by 
another executing program thread. 35 

27. A computer system comprising: 

means for assigning a multiplicity of program 
threads to a plurality of classes such that each 4o 
of said classes is assigned at least one pro- 
gram thread and at least one of said classes 
can be assigned a plurality of program threads; 

at least one processor; 45 

means for assigning a priority level to each of 
said program threads, to affect execution or- 
der; 

50 

means for selecting at least one available pro- 
gram thread from each of said class s for 
execution by said processor or processors 
when said processor or processors are avail- 
able, said selection being based at least in part 55 
on the relative priority levels of th program 
threads within each of said classes; 



means for preempting execution of a program 
thr ad from any of said classes with a high r 
priority lev I program thread from anoth r 
class; and 

means for preventing a program thread In said 
one class, which was made available after se- 
lection by the selecting means of another, low- 
er priority program thread from said one class 
for execution, from preempting execution of 
said other, lower priority program thread In 
said one class. 

2a A computer system as set forth in claim 27 
further comprising means for designating a 
maximum number of program threads to be 
run concurrently from said one class on dif- 
ferent processors. 

29. A computer system as set forth in claim 27 
further comprising means for positioning a re- 
presentation of the highest priority program 
thread which is available for execution from 
each class onto a run list for subsequent ex- 
ecution by one or more processors. 

30. A computer system as set forth In claim 29 
further comprising means for selecting the 
highest priority thread on the run list for execu- 
tion by the next available processor. 

31. A computer system as set forth in claim 29 
wherein the preventing means prevents more 
than one program thread from any class, from 
being positioned on the run list at any on 
time. 

32. A computer system as set forth in claim 27 
wherein said system comprises a plurality of 
said processors, and further comprising means 
for selecting a plurality of program threads 
from said one class for execution on a like 
number of said processors. 

33. A computer system as set forth in claim 32 
wherein said plurality of program threads from 
said one class have the highest priority levels 
of all program threads in said one class that 
are available for execution. 

34. A computer system as set forth in claim 27 
further comprising means for r questing that 
one of said program thr ads that Is currently 
executing ceas to xecute. 

35. A computer program product comprising: 
a computer readable medium; 
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first program instruction nr^eans. record d on 
said medium, for instructing a computer pro- 
cessor to receive identifications of program 
threads and classes in which said program 
threads reside; 

second program instruction means, recorded 
on said medium, for instructing a computer 
processor to assign said program threads to 
said classes according to said identifications; 

third program instruction means, recorded on 
said medium, for instructing a computer pro- 
cessor to select one of the program threads for 
execution; 

fourth program instruction means, recorded on 
said medium, for instructing a computer pro- 
cessor to prevent another one of the program 
threads in the same class as the one selected 
for execution from preempting the execution of 
the selected program thread; 

fifth program instruction means, recorded on 
said medium, for Instructing a computer pro- 
cessor to permit a program thread from an- 
other class to preempt execution of said se- 
lected program thread with a program thread; 

wherein each of said program instruction 
means is executable by the associated com- 
puter processor. 

36- A computer program product as set forth in 
claim 35 further comprising sixth program in- 
struction means, recorded on said medium, for 
instructing a computer processor to permit any 
program thread to voluntarily relinquish control 
of the associated processor, whereby another 
program thread from the same or different 
class can execute in place of said program 
thread which voluntarily relinquished control of 
said processor; and 

wherein said sixth program instruction means 
is executable by the associated processor. 

37. A computer program product as set forth in 
claim 35 further comprising sixth program in- 
struction means, recorded on said medium, for 
instructing a computer processor to assign a 
priority lev I to ach of said program thr ads 
to form a basis for interclass preemption, and 
wherein 

said program thr ad from said other class has 
a higher priority level than the preempted pro- 



gram thread from said one class; and 

said sixth program instruction means is execut- 
able by the associated processor. 

5 

38. A computer program product as set forth in 
claim 37 further comprising seventh program 
instruction means, recorded on said medium, 
for instructing a computer processor to repre- 

10 sent the highest priority level program thread 

which is available for execution from each 
class on a run list for subsequent execution by 
one or more computer processors, and 
wherein said seventh program instruction 

75 means is executable by the associated proces- 

sor. 

39. A computer program product as set forth in 
claim 38 further comprising eighth program 

20 instruction means, recorded on said medium, 

for instructing a computer processor to ex- 
ecute the highest priority program thread on 
the run list before executing the other program 
threads on the run list, and wherein said eighth 

25 program instruction means is executable by 

the associated processor. 

40. A computer program product as set forth in 
claim 39 further comprising 

30 

ninth program instruction means, recorded on 
said medium, for instructing a computer pro- 
cessor to halt execution of a cunently execut- 
ing program thread; and 

35 

tenth program instruction means, recorded on 
said medium, for instructing a computer pro- 
cessor after execution of the currently execut- 
ing program thread is halted to select for sub- 
40 sequent execution the highest priority program 

thread which is available for execution from the 
class containing the program thread whose ex- 
ecution was halted; and 

45 wherein said ninth and tenth program instruc- 

tion means are executable by the associated 
processor. 

41, A computer program product as set forth in 
50 claim 35 further comprising; 

sixth program instruction means, recorded on 
said medium, for instructing a computer pro- 
cessor to request that said one program thread 
55 cease execution; 

seventh program instruction means, recorded 
on said medium, for instructing a computer 
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processor to ceas to execute said one pro- 
gram thr ad in r sponse to said request; and 

wherein said sixth and seventh program in- 
struction means are executable by the asso- 5 
ciated processor. 
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